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Methode de transmission de services numSrIques sur un r6seau et 

appareil mettant en oeuvre la m^thode 

La presents invention concerne la transmission de services 
num6riques et plus particulierement selon la norms DVB. diffusion video 
num6rique (« Digital Video Broadcasting » en anglais). DVB definit un 
service comme « une sequence de programmes sous le controle d'un 
operateur pouvant etre diffuses dans le cadre d'une programmation », sur un 
r6seau g§neralement de type broadcast (ten-estre, cable ou satellite), mais 
aussi depuis recemment sur un r§seau de type IP, c'est a dire supportant le 
protocoie IP. protocols Internet (« Internet Protocol » en anglais). On peut 
trouver la specification du protocoie IP dans les RFC, requite pour 
Gommentaire (« request for comments » en anglais), maintenu par I'lETF, 
groups ds travail d'ingenierie Internet (« internet Engineering Task Force » 
en anglais) sous le numero 791 . 

■ 

La decouverte des services numeriques offerts par un reseau est 
normalises par DVB dans le cadre d'un r6seau de transmission par satellite, 
par c§ble ou numerique terrestre. Cette norme est decrite dans le document 
« Digital Video Broadcasting (DVB) ; Specification for Service Information 
(SI) in DVB Systems » public par I'ETSI, Tlnstitut europeen de 
standardisation des telecommunications (« European Telecomunication 
Standard Institute » en anglais) sous le numero ETSI EN 300 468. Ce 
document d§crit un ensemble de tables contenant des informations sur le 
reseau, sur les frequences auxquelles sont transmis les flux de donnees 
contenant les services, sur les services proposes etc. On peut 6galement se 
referer au document « MPEG-2 systeme - ISO lEC 13818-1 » pour la 
definition du format du flux de transport. Un flux de transport contient done 
des donnees audio, des donnees video, des donnees annexes comme des 
sous-titres, du teletexte ou des applications interactives sous la forme de flux 
eiementaires, ainsi que des tables de signalisation minimum obligatoires 
permettant d'organiser ce contenu comme la table d'information sur le 
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reseau (NIT pour « Network Information Table ») qui permet de retrouver les 
autres flux de transport sur le r6seau, la table d'associatlon des programmes 
(PAT pour « Program Association Table » en anglais) at la table 
d'organlsation des programmes (PMT pour « Program Map Table » en 
anglais) entre autres. Ces tables sont multiplexdes dans le flux de transport, 
le r^cepteur etant configure avec les donnees n§cessaires pour se 
connecter a un premier flux lui permettant de.recevoir ces tables et de 
construire, d'apres leur contenu, une base de donn§e contenant la liste des 
services offerts par le reseau et les donnees de connexion n§cessaires S 
leur reception. 

Le d^veloppement de r^seaux de transfert de donnees numeriques 
bidirectionnels, en partlculier du reseau Internet, et surtout la generalisation 
des acc6s a haut d6bit, offrent malntenant la possibility technique de diffuser' 
des services num§riques de type audlovisuels sur ce type de reseaux. 
□'autre part, des reseaux prives de type IP a haut debit se developpent, que 
ce solt au sein des entreprises ou dans le cadre du domicile. Dans ce cadre 
DVB travaille a la standardisation de la diffusion de services DVB sur les 
r6seaux de type IP. Un groupe de travail appele DVB-IPI, infrastructure sur 
protocole Internet (« Internet Protocol Infrastructure » en anglais) est en train 
de finallser une specification concernant le transport des services 
numeriques DVB sur un reseau de type IP, et plus particuli§rement la 
decouverte de ces services. La proposition telle qu'envisag6e aujourd'hui est 
pr6sent6e dans le document « DVB-IP Phase 1 Handbook » sous la 
reference IPI2003-227. La solution, telle qu'envisag^e actuellement par le 
groupe de travail, s'oriente vers une separation entre la diffusion des 
sen/Ices sous la forme de flux de transport contenant un seul service DVB 
d'une part et les informations decrivant ces services, disponibles sous la 
forme de fichlers XML (extensible Markup Language) accessibles pour les 
terminaux sur requete par exemple. Le protocole HTTP (Hyper Text 
Transport Protocol) pouvant, par exemple. atre utilis6 pour retrouver ces 
fichlers. Cette solution semble naturelle car elle tire profit du caract^re 
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bidirectionnel de la connexion IP contrairement a la transmission par satellite 
par exemple. En effet les nornnes telles que DVB ont 6t6 congues dans 
I'optique d'un r§seau de transmission unidirectionnel imposant la 
transmission permanente de toutes les informations susceptibles d'etre utiles 
5 a un r6cepteur. Le caractere bidirectionnel des reseaux envisages permet de 
distlnguer les informations utiles au decodage du service audlovlsuels et les 
informations de description des services. Ces deux types d'informations 
traditionnellement pr§sentes dans un flux DVB ne sont pas utilisees de 
maniere synchronisee par le recepteur. Leur transmission sur le reseau va 
10 done pouvoir etre s§par6e. ce qui permet d'economiser la bande passante 
en ne transmettant les informations de signalisation qu'^ la demande et non 
en pemianence dans le canal audio et video. De plus, la mise ^ disposition 
d'informations sur un reseau de type IP via des serveurs HTTP sous la 
forme de fichiers de donnees en XML est la solution dominante largement 
15 adopt§e sur ce type de reseau. 

Mais cette solution impose le developpement d'un ensemble d'outils 
permettant de gen^rer et de gerer les serveurs offrant ces informations, de 
signalisation au format XML. Or a I'heure actuelle. les diffuseurs de contenu 
20 disposent d'une infrastructure maTtrisee pour la diffusion de services MPEG- 
2 DVB via le satellite ou le cable. L'adoption de ce nouveau schema de 
signalisation imposant le developpement. en parallele du systeme existant, 
de nouveaux outils implique un investissement et une prise de risque pour 
les op§rateurs. De plus, les terminaux n'integrent pas aujourd'hui les outils 
25 necessaires a I'analyse de ces informations, comme par exemple, un 
analyseur XML. L'int§gration de tels outils dans un recepteur a faible cout 
peut s'averer delicate voire impossible en fonction des ressources 
mat^rielles disponibles comme la puissance du processeur ou la m6moire. 

30 L'invention permet d'offrir une methode de transmission de services 

numerique sur un reseau de transmission de donnees bidirectionnel et plus 
particuli§rement la d§couverte des services offerts sur le r6seau par un 
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recepteur. Cette methode, utilisee dans le cadre da DVB, permet la 
reutilisation en grande partie de la chaTne de production actuellement 
deployee de services DVB pour le satellite ou le cSble, Cette m^thdde doit 
6galement permettre de limiter la bande passante utilisee pour la diffusion 
des informations permettant ia decouverte des services. 

Uinvention concern© une m6thode de decouverte, par un 
recepteur connecte a un r6seau bidirectionnel. de services numeriques sur le 
r6seau bidirectionnel qui comporte une 6tape oQ le recepteur se connecte a 
un premier flux, une etape ou le recepteur extrait dudit flux des informations 
sur la localisation sur le reseau d'une part de flux vehiculant le contenu de 
ces services et d'autre part de flux separes, vehiculant des informations de 
description de ces services, une 6tape ou le recepteur se connecte a au 
moins une partie des flux v6hiculant les informations de description des 
services de fa9on a obtenir des informations sur ces services et une etape 
oil le recepteur utilise ces informations pour construire une liste 
§ventuellement unitaire des services disponibles surle r6seau. 

Selon un mode particulier de I'invention toutes les tables de 
signalisations relatives ^ un service sont contenues dans au mains un flux 
different du flux vehiculant le contenu dudit service. 

Selon un mode particulier de Tinvention la methode comporte une 
§tape de test de correspondance entre un identificateur et un filtre contenu 
dans le descripteur d'un flux permettant de determiner si une table 
possedant cet identificateur est disponible dans ledit flux. 

Selon un mode particulier de Tinvention la premiere adresse IP de 
diffusion et le premier num§ro de port sont entres par Tutilisateur. 

Selon un mode particulier de invention la premiere adresse IP et le 
premier numdro de port sont obtenus du r6seau par le r6cepteur. 
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Selon un mode particulier de Tlnvention les flux ne contiennent qu'un 
seul service DVB. 

Selon un mode particulier de I'inventlon la lists des services est 
incluse dans la NIT contenue dans le flux disponible ^ la premiere adresse 
IP de diffusion sur le premier port. 

L'invention concerne egalement un appareil poss^dant des moyens 
de se connecter a une adresse IP de diffusion via des moyens de connexion 
a un r§seau IP et des moyens de decodage de flux DVB diffuse a cette 
adresse IP de diffusion, caract^rise en ce que les moyens de decodage de 
flux DVB ont la capacite d'analyser une NIT, extraite du flux, contenant des 
descripteurs de reseau adaptes au reseau IP et de se connecter ^ chaque 
adresse IP de diffusion d6crite dans ladite NIT pour y lire un flux DVB et en 
extraire les informations sur les serylces offerts sur le reseau 
pref6rentiellement selon Tune quelconque des m^thodes selon les 
revendications precedentes. 

L'invention concerne 6galement un descripteur d'un service de 
diffusion d'un flux DVB destine a §tre Indus dans une NIT caracterise en ce 
qu'il contient I'adresse IP de diffusion d'un serveur de flux et un numero de 
port sur lequel ledit serveur diffuse un flux DVB vehiculant le contenu d'un 
service sur un reseau de type IP et au moins un descripteur contenant 
I'adresse IP. de diffusion d'un serveur de flux et un num§ro de port sur lequel 
ledit serveur diffuse un flux DVB. vehiculant des infomnations de signalisation 
relatives audit service. 

Selon un mode particulier de l'invention les au moins un descripteur 
contenant I'adresse IP de diffusion d'un serveur de flux et un numero de port 
sur lequel ledit serveur diffuse un flux DVB vehiculant des informations de 
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signalisation relatives audit service contiennent egalement le moyen.de 
tester la correspondance d'un identificateur avec un filtre, 

5 Uinvention sera mieux comprise, et d'autres particularites et 

avantages apparaTtront a la lecture de la description qui va suivre, la 
description faisant reference aux dessins annexes parmi lesquels ; 

La figure 1 repr6sente un schema de la chaTne de production de 
services DVB dans le cadre d'une diffusion satellite classique. 
10 La figure 2 represente un exemple d'architecture de flux de donn6es 

DVB dans le cadre d'un exemple de realisation de I'invention, 

La figure 3 represente un exemple d'architecture de flux de donn6es 
DVB dans le cadre d'un autre exemple de realisation de ('invention. 

La figure 4 represente le fonctionnement d'un recepteur dans le cadre 
15 d'un exemple de realisation de Tinvention, 

La figure 5 represente un schema de la chaTne de production de 
services DVB dans le cadre d*un exemple de realisation de Tinvention. 

La figure 6 repr6sente la structure d'une NIT (Network Information 
Table) selon la norme DVB. 
20 La figure 7 represente la structure d'un decodeur numerique standard, 

par exemple dans le cas d'une reception terrestre. 

La figure 8 represente la structure d'un decodeur numerique adapte a 
la reception sur IP. 

La figure 9 represente un organigramme de la phase de decouverte 
25 des services. 

La figure 10 represente un organigramme de la phase de lecture des 
informations sur les services. 

Uexemple de realisation de Tinvention concerne la transmission de 
30 services DVB sur un reseau IP mais peut s'appliquer e tout autre systeme de 
transmission de services numerique sur un reseau de transmission de 
donnees bidirectionnel. 
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La connexion a un serveur sur un r6seau de type IP peut se faire 
selon un protocols de diffusion multipoint (« IP multicast » en anglais). Un 
exempie d*un tel protocole est ie protocole IGMP (Internet Gateway 
Management Protocol) d§fini dans ia RFC 2236. Dans ce protocole, ^ un 
serveur de diffusion multipoint est associe una adresse de diffusion 
multipoint. Cette adresse a le format d*une adresse IP, dans un domaine 
j-^serve a cet usage, mais ne correspond pas a Tadresse IP d'une machine 
accessible sur le r6seau. Un recepteur desirant se connecter a ce serveur va 
envoyer une requete sur le reseau contenant cette adresse IP de diffusion 
multipoint. Cette requ§te va etre relayee dans tout le reseau jusqu'a 
atteindre le serveur en charge de cette diffusion qui va done inscrire le 
recepteur comme client de la diffusion. Les routeurs sur le chemin entre le 
serveur et le recepteur vont ensuite etre en mesure de relayer ies paquets IP 
constituant le flux vers les terminaux abonn6s a la diffusion. Une 
optimisation de ce protocole permet, par la connaissance de Tadresse IP de 
la machine serveur en sus de I'adresse IP de diffusion multipoint, d'optimiser 
la route de la requSte d'abonnement en I'acheminant directement vers le 
serveur destinataire au lieu de la diffuser dans tout le reseau. Cette 
optimisation est connue sous le nom de SSM (Source Specific Multicast). 
C'est done un systeme par abonnement S une diffusion de donnees 
numeriques. Un serveur diffuse des donnees numeriques, sous forme de 
paquets, sur le reseau. Tant qu'aucun recepteur ne s'abonne a cette 
diffusion, aucun paquet n*est reellement transmis. Quand un recepteur 
s'abonne, les paquets lui sont transmis par un acheminement a travers le 
reseau suivant une route entre le serveur et le client. Le protocole assure 
que les paquets ne vont emprunter que les routes du r6seau menant ^ des 
recepteurs effectlvement abonnes a la diffusion. Lorsqu'un recepteur se 
desabonne, la transmission effective des paquets vers ce recepteur cesse. 
Le protocole assure egalement que les paquets ne sont pas dupliques sur 
une portion de route du reseau menant a plusieurs recepteurs abonnes & la 
diffusion. 
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La transmission des donnees constituant le sen/ice peut 6galement 
se faire selon un protocoie de diffusion unipoint (« IP unicast » en anglais), 
Un exemple d'un tel protocoie est le protocoie de transfert de flux en temps 
5. reel RTSP (« Real Time Streaming Protocol » en anglais) defini dans la RFC 
2326. Ce protocoie servant ^ controler la diffusion du flux sur IP. 11 est prevu 
pour fonctionner conjointement avec un protocoie de diffusion proprement dit 
comme RTP. La principale difference avec la diffusion multipoint etant qu'& 
chaque client d^sirant se connecter sur le flux, le serveur va initier une 

10 diffusion point a point entre lui-meme et le client. II est evident que cette 
solution est plus dispendieuse en bande passante que la solution basee sur 
la diffusion multipoint. En effet, dans cette solution les paquets de donnees 
transitant sur une portion de route du r^seau menant d plusieurs recepteurs 
abonn§s sont dupliques autant de fois qu'il y a de recepteurs abonnes. Cette 

15 solution est envisageable dans le cadre d'un reseau restreint ou seul un petit 
nombre de terminaux sont susceptibles de se connecter a un flux. 

De fagon a limiter la bande passante utilisee a la diffusion des 
ser^/^ices DVB sur un reseau IP tout en limitant les modifications a apporter ^ 

20 la chaTne de production de services utilisee chez les operateurs qui offrent 
deja des services de ce type sur d'autres supports de transmission comme le 
satellite ou le cable, nous allons adopter une organisation des donnees 
constituant les services comme suit. D'une part un flux, dit d'installation, va 
contenir une table d'information sur le r6seau fortement derivee de la NIT de 

25 DVB et seulement cette table que nous appelons NIT modifi^e dans le sens 
. ou elle reprend la syntaxe de la NIT DVB mais contient des descripteurs 
specifiques, adaptes ^ la diffusion de services DVB sur IP. D'autre part les 
services vont etre s6pares en un flux de contenu qui va rassembler les flux 
6l6mentaires du service, audio, video, sous-titres, etc, ainsi que la 

30 signalisation minimum permettant d'organiser ces flux elementaires comme 
la PAT et la PMT et en flux de description ne contenant que des informations 
de description sur les services. Seuls les flux de contenu vont consepw^er le 
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format de flux de transport tel qu'il est d§finit par MPEG-2. Les flux 
d'installation et de description sont directement constitues des tables telles 
que la NIT pour le flux d'installation et les SDT ou autres pour les flux de 
description. Ces tables suivent la syntaxe des sections l\/IPEG-2. En effet, 
Tacces aux informations de description des services est un besoln ponctuel 
non correle au besoln de decoder le contenu audio et video. Les bandes 
passantes actuelles sur IP et le besoin de limiter la bande passante sur le 
reseau rendent probable la creation d'un flux par service mais le 
multiplexage de plusieurs services sur un flux est possible dans le cadre de 
rinvention. 



Pour adapter la NIT a une utilisation sur un reseau IP, il est 
necessaire de d6finir des descripteurs adaptes a la localisation de flux sur un 
reseau IP, Un tel descrlpteur adapte d la diffusion multipoint est donne ci- 
dessous : 



No de bits identifieur 



8 
8 

32 
16 
8 

32 



uirasbf 

uimsbf 

bslbf 

bslbf 

bslbf 

bslbf 



Syntaxe 

Ip_streani_descriptor () ( 
Descriptor__tag 
Descriptor_length 
Content_multicast_address 
Content_multicast_port_number 
Content_muiticast_protocol_mapping 
Content_source_address 

For (i^O; i < N; i++) { 
Descriptor ( ) 

} 

} 

Le champ « Descriptor_tag » est un identlfiant con-espondant k ce 
nouveau type de descripteur. 

Le champ « Descriptorjength » donne la taille du descripteur. 

Le champ « Content_multicast_address » est Tadresse IP de diffusion 
multipoint du sen/eur sur lequel est disponible le flux de contenu. 

Le champ « Content_multicast__port__number » est le numero de port 
sur le serv.eur ou Ton doit se connecter pour recevoir le flux de contenu. 
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Le champ « Content_multicast_protocol_mapping » est un champ 
identifiant le protocole de codage du, ou des, service diffuse a cette adresse. 
Ce protocole peut §tre MPEG-2. IVIPEG-4. MHP ou autres. Ce champ, 
optionnel, peut permettre de filtrer sur le type de contenu pour ne retenir que 
les services que le recepteur est ^ m§me de decoder. 

Le champ « Content_source_address » est I'adresse IP reelle du 
serveur ce qui permet un routage efficace de la requite de connexion ^ un 
serveur de diffusion multipoint selon le protocole SSM. 

La boucle sur les descripteurs permet de gerer les descripteurs de 
localisation du, ou des, flux de description relatifs au service dont le contenu 
est diffuse a I'adresse precedemment d§finie. 

Nous donnons ci-dessous la definition d'un autre exemple d'un tel 
descripteur adapts a la diffusion unipoint : 



Ip_streain_descriptor () { 

Descriptor_tag 

Descriptor_length 

Content_unicast_acldress 32 

Content_unlcast_port_number 

Content_unicast_protocol_inapping 
For (i=0; i < N; i++) { 

Descriptor () 

} 

} 



8 
8 

16 
8 



bslbf 



uimsbf 
uimsbf 

bslbf 
bslbf 



Le champ « descrlptor_tag » est un identifiant correspondant ^ ce 
nouveau type de descripteur. 

Le champ « descriptorjength » donne la taille du descripteur. 

Le champ « Content_unicast_address » est I'adresse IP de diffusion 
unipoint du serveur sur lequel est disponible le flux vehiculant le contenu. 

Le champ « Content_unicast_port_number » est le num§ro de port 
sur le serveur ou I'on doit se connecter pour recevoir le flux v§hiculant le 
contenu. 



1 er cl6p6t 
11 



« 

Le champ « Content_unicast_protocoLmaPPing » champ 
identifiant le protocole de cpdage du, ou des, service diffus6 ^ cette adresse. 
Ce protocole peut §tre MPEG-2, MPEG-4, MHP ou autres. Ce champ, 
optionnel, peut permettre de flltrer sur le type de contenu pour ne retenir que 
les services que le recepteur est a m§me de decoder. 

La boucle sur les descripteurs permet de gerer les descripteurs de 
localisation du, ou des, flux de description relatifs au service dont le contenu 
est diffuse a I'adresse pr6cedemment definie. 

Nous voyons dans la structure de la NIT de DVB, et done de la NIT 
modifi§e qu'il existe une boucle sur les flux de transport, ce qui veut dire que 
tous les flux de transport constituent le r6seau complet d'un operateur 
peuvent etre decrits dans cette boucle. De cette fagon, le recepteur peut 
construire une liste avec les adresses IP de diffusion multipoint ou unipoint 
de tous les flux de transport d'un reseau de diffusion de t§16vision large 
bande sur IP. Une liste de descripteurs de services peut etre 
optionnellement incluse dans la NIT modifi^e de fa9on a acc6l6rer la phase 
d'installation du recepteur. 

On peut egalement envisager que des sen/eurs de flux multipoint et 
unipoint soient presents dans le meme reseau. 

Dans une autre implementation plus sophistiqu§e, les descripteurs de 
localisation des flux de description des informations relatives au service 
diffuse peuvent par exemple prendre la forme suivante : 



Ip_stream_multicast_locator_descriptor () { 

Descriptor_tag 
Descriptor_iengtli 
Filter_length 
Filter_descriptor ( ) 
inulticast_address 
inulticast_port_number 
multicast_pEOtocol_mapping 



8 uirasbf 
8 ulmsbf 
8 uimsbf 



32 bslbf 
16 bslbf 
8 bslbf 



1 er depot 



12 

source_acidress 32 bslbf 

•1 

Nous retrouvons ici les champs classiques d'un descripteur 

5 permettant la localisation d'un flux diffus6 sur IP en multipoint. Seuls les 
champs « FHterJength » et « Filter_descriptor » m^ritent une explication. En 
fait, dans le cadre de Texemple de realisation de I'invention, les Informations 
de description du service sont separ6es des informations de contenu. elles 
sont vehiculees dans un seul flux different. Mais il est egalement possible de 
10 vehiculer ces informations de signalisation, ces tables, dans une plurality de 
flux differents. C'est precisement pour prendre cette possibilite en compte 
que le descripteur « lp_stream_descriptor » contient une boucle. Mais quand 
on parcourt ce descripteur, on ne sait pas ^ priori quel flux dans la boucle de 
descripteurs va contenir une table donnee que Ton recherche pour le 

15 service concern^ par le descripteur. Le fait dMntroduire les champs 
« Filterjength » et « Filter_descriptor » dans le descripteur pemnettent 
d'implementer un moyen de stocker dans le descripteur des informations 
permettant de savoir quelles sont les tables contenues dans chaque flux de 
la boucle. Une fagon de coder cette information peut. par exemple, etre de 

20 mettre dans ce champ « FiIter_descriptor » les chaTnes de bits qui 
permettent par exemple de programmer un demultiplexeur pour filtrer 
lesdites tables. Chaque type de table possedant un identificateur donne, on 
peut mettre dans le filtre la chaTne binaire representant I'identificateur de la 
table contenue dans le flux. Dans le cas ou Ton veut pouvoir avoir plusieurs 

25 tables dans le flux, on peut adopter la m§thode utilisee pour programmer le 
filtre du demux. Une premiere chame binaire indique un identificateur que 
I'on veut filtrer et une deuxi^me chaTne de la meme longueur indique pour 
chaque bit de la premiere si cette valeur est definie ou non. Un identificateur 
donne va done correspondre au filtre si pour chaque bit de cet identificateur 

30 pour lequel le bit correspondent de la deuxieme chaTne binaire est ^ un, le 
bit correspondant de la premiere chaTne a la mSme valeur. Par exemple, si 
on prend des chaTnes sur trois bit, une premiere chaTne binaire d'une valeur 
de Ob101, une deuxiSme chaTne d'une valeur de 0b110, les Ideritificateurs 
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correspondant a ce filtre auront les valeurs Ob101 et Ob100. Cette methode 
permet de definir les tables contenues dans le flux de la meme fa9on que 
Ton programmerait un demultiplexeur pour les retrouver. 

Dans une autre implementation plus simple, les descripteurs de 
localisation des flux de description des informations relatives au service 
diffuse peuvent par exemple prendre la forme suivante : 

Ip_streara_multicast_locator_descriptor_table_ids {) { 

Descriptor_tag 8 uimsbf 

' Descriptor^length 8 uimsbf 

NbOfTablelDs 8 uimsbf 

TablelDList () 

multicast_address 32 bslbf 

. . mult i cast __port_n umber 16 bslbf 

multicast_protocol_mapping 8 bslbf 

source_address 32. bslbf 

} 

Nous retrouvons ici les champs classiques d'un descripteur 
permettant la localisation d'un flux diffuse sur IP en multipoint. Seuls les 
champs « NbOfTablelDs » et « TablelDList » meritent une explication. 

Le champ « tablelDLIst » correspond a une liste des Identificateurs de 
tables qui sont inclus dans le flux correspondant, et le champ 
« NbOfTablelDs » repr6sente le nombre d'identificateurs de tables listees. 
Ainsi, un flux contenant a la fols des informations concernant les 
Informations de signalisation sur les evenements actuels et suivant du flux 
. courant dont Tidentificateur de table est 0x4E et les informations de 
signalisation sur les evenements actuels et suivant des autres flux dont 
ridentlficateur.de table est 0x4F, aura un descripteur avec la valeur 2 pour le 
champ « nbOfTablelds » et les valeurs 0x4E et 0x4F dans le champ 
« tablelDList ». 

Une autre possibilite d'implementation de la diffusion des flux 
contenant les informations de signalisation peut etre de choisir un simple 

§ 

protocole de transfert de fichiers entre le serveur et le recepteur au lieu de la 
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diffusion multipoint. Un tel protocole peut, par exemple, etre le protocole 
HTTP (« HyperText Transfert Protocol »). Ce protocole est simple a 
implementer, surtout si I'on se limite a impl^menter la capacite de faire un 
« GET » permettant d'obtenir un fichier sur un serveur. Ce protocole est bien 
moins lourd k gerer que le traitement des fichiers XML evoque dans 
I'introduction. Dans ce cas, 11 est n6cessaire d'avoir un autre descripteur 
comme par exemple le descripteur suivant qui permet d'associer a une table 
d'identificateur donn6, I'URL (« Universal Resource Locator ») du fichier la 
contenant : 

Ip_stream_HTTP_locator_descriptor () { 

Descriptor_tag 8 uimsbf 

Descriptor_length 8 uimsbf 

Table_id 8 bslbf 

For (i=0; i<N; { 

Char 8 bslbf 

} 

} 

Mais, cette fagon de faire n'est pas le mode prefere de realisation de 
i'invention. car la diffusion par HTTP, comme d'ailleurs la diffusion unipoint 
des ces tables de signalisation implique une duplication du flux de donnees 
sur le r6seau pour chaque recepteur voulant s'installer. Mais c'est tout de 
m§me un mode de realisation envisageable sur des r6seaux ne contenant 
pas un grand nombre de r^cepteurs, comme des r6seaux domestiques. 

La figure 1 decrit I'architecture g6n6rale d'une chaTne de production 
de services MPEG-2 DVB dans le cadre d'une diffusion satellite. Au depart 
de la ChaTne, nous avons du contenu audio et vid§o 1.1 qu'il s'agit de 
diffuser. Ce contenu est encod6 selon la norme MPEG2 dans un codeur 1.2 
pour generer un flux 6l6mentaire audio/vid^o 1.5. Parallelement au codage 
de I'audio et de la video, les informations de signalisation 1.3 sont gen^rees. 
elles proviennent generalement d'une base de donn6es contenant les 
informations descrlptives sur le service que I'oh veut diffuser. Ces 
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informations sont g6n6r6es sous la forme d'un flux de signalisation 1.6. Un 
autre module 1.4 prend en cliarge la g6n6ration d'un flux de sous-titres 1.7. 
II est egalement possible d'inclure un flux d'applicatlons interactives 1 .8, dont 
la chaTne de production n'est pas detaillee ici. Tous ces flux elementaires, 
avec 6ventuellement d'autres flux vehiculant d'autres contenus audio et 
video, la signalisation s'y rapportant ou autre, sont ensuite multiplexes dans 
un multiplexeur 1 .9 pour g6n6rer le flux de transport IVIPEG-2 qui va etre 
ensuite module et convert! sur une frequence choisie par le modulateur 
convertisseur 1.10. Un ensemble de flux de ce type peuvent etre melanges 
par un m^langeur 1.11 pour un envoi sur un satellite 1.13 via une station 
d'emission 1.12. Dans ce cas une synchronisation des inforrnations de 
signalisation est necessaire entre les differents flux de fagon a inclure des 
informations sur les autres flux dans les tables descriptives de chaque flux. 
Ces programmes peuvent ensuite §tre regus au domicile de I'utilisateur via 
sa parabole 1.14 pour §tre decodes par un decodeur et affiches sur un 
televiseur. Cette chaTne est maintenant bien maltris^e par les op6rateurs. 

La figure 2 represente un exemple d' architecture de flux suivant un 
exemple de realisation de I'invention. Dans cet exemple, un premier flux 2.1 , 
appele flux d'installation est montre. Ce flux d'installation ne contient pas de 
contenu audio ou vid6o. mais seulement la NIT modifiee 2.4 contenant les 
informations sur le r§seau. Ce flux d'installation peut directement utiliser la 
syntaxe d'une section MPEG-2 et peut ne pas posseder I'encapsulation sous 
la forme d'un flux de transport du fait que les donnees sont directement 

transmises sur le r6seau IP. 

Cette NIT modifi6e d^crlt plusieurs flux contant des services. La 
structure standard d'une NIT telle que d§finie par DVB est donn6e figure 6. 
Bien qu'un flux, quel que soit le moyen de transmission, puisse contenir 
plusieurs sen/ices DVB, 11 est probable que seuls des flux ne contenant qu'un 
sen/ice DVB soient utilises dans un premier temps dans le cadre de la 
diffusion sur IP et ceci pour des raisons de bande passante. L'exemple d6crit 
sur la figure 2 se place done dans ce cas. Mais 11 est Evident que I'invention 
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ne se limite pas S Tutilisation de flux ne contenant qu'un service DVB dans le 
flux. Nous avons done dans la NIT modifiee 2.4 la description de trois 
services 2,5. 2.6 et 2.7. La description d'un service va contenir des 
descripteurs 2.8 et 2.9 permettant de localiser le flux de contenu 2.2 ainsi 
que le flux contenant la description relative au service 2.3. Le flux de 
contenu 2.2 va contenir une PAT (« Program Association Table ») pointant 
sur les contenus reiatifs a un service 2.11 constitu6 d'une PMT (« Program 
Map Table »). Le flux de description 2.3 est done un flux separ6 d*u 
precedent. Ce flux ne possede pas le format des flux de transport MPEG-2 
mais directement des tables ayant la syntaxe d'une section MPEG-2. Cette 
separation permet a un client de ne se connecter sur ce flux que lorsqu'il doit 
acc6der aux informations de description et evite done d'utiliser de la bande 
passante pour une diffusion permanente de ces informations. Ainsi 
Tutllisation de cette bande passante est amelioree. Rappelons que dans la 
diffusion sur IP, lorsqu'un r^cepteur se desabonne d'une difl'usion, la 
transmission effective des paquets sur le reseau a destination de ce 
recepteur cesse. Dans I'exemple, le flux de description contient les 
informations sur les evenements 2.14, comme Tinformation sur Tev^nement 
courant, le suivant, ainsi que 6ventuellement le calendrier complet des 
evenements permettant la construction d*un guide electronique de 
programme. II contient egalement, les informations sur le sen/ice 2.13, 
comme la SDT (« Service Description Table »). 

La figure 3 est un autre exemple d'architecture de flux suivant un 
exemple de realisation de Finvention. Get exemple ressemble beaucoup au 
precedent tel que represente sur la flgure 2. La difference vient du fait que. 
ici, les informations de description relatives aux evenements et celles 
relatives au service sont portees par deux flux diff^rents. Nous avons done 
ici pour le service 1 3.5, trois descripteurs de flux 3,8, 3.9 et 3.10 au lieu des 
deux precedents pointant sur le flux des contenus 3.2, celui des informations 
sur le sen/ice 3.3 et celui sur les evenements 3.15. II est done possible de 
repartir les differentes tables constituant les informations de signalisation sur 
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diff^rents flux en fonction des tables disponibles et de {'utilisation qui en sera 
faite de fagon a g6rer la bands passante du r^seau. On peut aussi prendre 
en compte les cpntraintes de gestion du service en regroupant les tables 
ayant la m§me frequence de mise a jour. 



La figure 4 represente un scliema d'acteurs decrivant la phase de 
d6couverte des services presents sur le reseau. Les entites representent 
d'une part I'utilisateur du systdme qui est devant son recepteur, le r^cepteur 
ainsi que les flux d'installation, de contenu d'un service et de description de 
ce meme service. D'autres flux relatifs a d'autres services peuvent etre 
presents dans le reseau mais ne sont pas representes sur la figure. Dans un 
premier temps I'utilisateur met son r6cepteur sous tension. Le recepteur se 
connecte alors au flux d'installation. Le recepteur possdde des paramdtres 
lui permettant une premiere connexion a une adresse IP de diffusion 
multipoint ou unipoint. La solution la plus simple est de consid^rer que cette 
adresse IP de diffusion est entree manuellement dans un menu de 
configuration. Cette adresse IP de diffusion peut egalement §tre attribuee au 
recepteur lore de la phase de connexion via des protocoles comme DHCP 
(Dynamic Host Control Protocol) ou PPP (Point to Point Protocol). Mais touts 
autre m6thode de determination de cette premiere adresse IP est possible. 
Cette adresse consiste en une adresse IP de diffusion multipoint.ou unipoint 
et un num^ro de port correspondant. Le flux d'installation est diffuse a cette 
adresse. 

Une fois que le recepteur est connect6 au flux d'installation, il est 
done en mesure de d§coder la NIT mpdifiee et de lire les Informations qu'elle 
contient. Le recepteur est done t m§me de cr6er une liste des services 
disponibles sur le reseau. Le parcours de cette liste lui donne accds aux 
adresses de diffusion des flux de contenu et des flux de description diffuses 
sur le reseau. Le recepteur est done en mesure de se connecter 
successivement a ces flux de fagon ^ collecter les informations sur les 
services, dont le nom de chaque service. 11 est done possible ensuite. pour le 
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recepteur, de pr6senter^ Tutiiisateur la liste des services. Uutilisateur choisit 
ensuite \e service qu'il d§sire regarder, le r^cepteur utilise le descripteur du 
flux de contenu trouv6 dans la NIT modlfiee pour le service choisi et se 
connecte au flux de contenu du service choisi. Le decodage et Taffichage du 

5 service choisi peut alors commencer. Si ensuite, I'utilisateur desire acc6der 
aux informations sur r6v6nement courant et sur I'^v^nement suivant, il 
envoie una requete dans ce sens, le recepteur va utiliser, encore une fois le 
descripteur contenu dans la NIT modifi§e pour y trouver la localisation sur le 
reseau du flux de description contenant les Informations sur les 6venennents. 

10 Ces Infornnations peuvent etre contenues dans le meme flux que les 
informations de description du service ou dans un flux sfepare comnne d6crit 
sur les figures 2 et 3, Le recepteur se connecte alors ^ ce flux et r6cupere 
les informations sur les ev6nements de fagon a §tre en mesure de les 
afficher a I'utilisateur. 

15 

La connexion du recepteur S un flux peut se faire par exemple via le 
protocole IGMP. Generalement ce flux de transport est du type MPEG-2 
encapsule sur IP en utilisant les couches de protocole iP/UDP/RTP (User 
Datagram Protocol. Real Time Protocol), mais ce peut etre egalement un 
20 flux de type MPEG-4, MHP ou autre. 

La figure 5 repr6sente la chaTne de production des flux selon 
rinvention. D'une part le contenu audio et video brut 5,1 est encode par 
Tencodeur 5.4 pour donner les flux 61ementaires audio et video 5.7. Une 

25 base de donnees 5.2 contient toute la description des services ainsi que les 
informations sur les ev6nements. Un module 5.5 pennet de construire les 
tables de signalisation 5.8 avec ces informations. Les informations de 
signalisation 5.8, les flux de contenu audio et video 5.7, ainsi que d'autres 
Informations optionnelles telles que des applications interactives ou autre 5.6 

30 sent multiplexees 5.9 pour construire un flux de contenu 5,10. Un premier 
module de formatage 5.11 utilise les tables de signalisation construites 5.8, 
6ventueilement des informations contenues dans la base 5.2 et des 
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informations additionnelles sur d'autres services 5.3 pour construire le flux 
de description 5.12. Un second module de formatage 5.13 utilise les 
infonnations additionnelles sur les services du r6seau 5.3 pour construire le 
flux d'installation 5.14 qui va contenir la description de tous les flux 
5 disponibles sur le r^seau avec les adresses permettant d'y acc6der. Les 
princlpaux modules qui n'existent pas dans la cliaine de production 
classique de services DVB sont ces modules de formatages 5.11 et 5.13. 
Mais ces modules sont simples a construire car ils se contentent de 
construire des flux contenant des tables de signalisation telles que celles qui 
10 sont d§]& construites par le module de signalisation 5.5. L'originalit§ venant 
de rutilisation des descripteurs adapt^s S la localisation d'un flux sur un 
reseau IP. que ce flux soit diffus§ en multipoint, unipoint ou encore 
disponible via un protocole de transfert de fichier tel que HTTP. Ces flux. 
5.10, 5.12 et 5.14. une fois construits peuvent done §tre diffuses sur les 
15 serveurs du reseau IP. 

La figure .7 decrit I'architecture d'un decodeur traditionnel. comme par 
exemple un d§codeur num6rique terrestre. Le decodeur 7.1 dispose d'un 
6cran 7.3. L'utilisateur 7.2 interagit grace a une application de navigation 7.4 
20 qui s'affiche sur I'^cran 7.3. L'ensemble des fonctions du decodeur est pilot6 
par une application de gestion traditionnellement appele « middleware » 7.5. 
Cette application de gestion pilote les modules materials qui sont le « tuner » 
7.8, le « demux » 7.7 et le decodeur 7.6. Le tuner est responsable de la 
recuperation du flux DVB regu par I'antenne 7.9. Ce flux est demultiplexe par 
25 le demux. c'est a dire que le demux est capable de reconstituer les differents 
flux.etementaires constituants le flux de transport DVB. tel que Taudid. la 
vid6o et les donnees auxiliaires (comme les sous-titres. le t§letexte ou une 
application interactive) ou telle ou telle table de signalisation. Dans le flux 
DVB, chaque flux elementaire est identifi§ par un identificateur et I'oh peut 
30 programmer le demux pour filtrer les flux elementaires qui nous interessent 
dans le flux complet qui est regu. Au moins les flux audio et video sont 
encodes de fagon & compresser et/ou crypter les informations qu'ils 
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contiennent, le decodeur est done la pour decompresser et/ou decrypter ces 
flux de maniere ^ restituer le contenu audio et video ^ Tutilisateur. 

La figure 8 quant a elle decrit un decodeur IP, adapts a la reception 
5 des flux DVB sur un reseau IP. On retrouve exactement la m§me 
. architecture que dans le cas du decodeur traditionnel a la difference que le 
tuner est remplace par une interface reseau 8.10 branch6e sur un r§seau IP 
8.11. 

10 La figure 9 detaille les etapes de la decouverte des services sur le 

reseau. La premiere etape consiste k obtenir le flux d'installation 9.1 . Ce flux 
est disponible sur le reseau. II existe de multiples fafons de mettre ce flux a 
disposition, on peut en citer au moins trois, ce flux peut Stre diffuse en 
multipoint, il peut egalement Stre diffuse en unipoint ou §tre disponible via un 

1 5 protocole de transfer! de fichier tei que, par exemple HTTP. Quel que soit la 
maniere de diffuser ce flux d'installation sur le r6seau, le decodeur doit etre 
en mesure de le retrouver, il doit done en connaTtre Tadresse ainsi que les 
parametres de connexion permettant de se connecter a ce flux. Cette 
premiere adresse peut soit Stre pr6sente dans la memoire morte de 

20 rappareil soit lui Stre communiquee par Tutilisateur ou encore §tre 
communiquSe S I'appareii par un serveur lors de sa connexion au r6seau via 
un protocole de connexion permettant I'acquisition de parametres tel que 
DHCP (« Dynamic Host Configuration Protocol ») ou PPP (« Point to Point 
Protocol »). Le r6cepteur se connecte au flux d'installation 9.2, puis il y 

25 cherche une NIT modifi6e 9.3. Lorsque cette NIT modifiee est trouvee, il y lit 
la description d'un premier flux de transport caracteris6 par son identiflcateur 
de flux de transport (« TSID ») et son identiflcateur de r§seau d'origine 
(« ONID ») 9.4. Ensuite. un flux de transport pouvant contenir plusieurs 
services, on commence a lire la description des services contenus dans (e 

30 flux de transport. Pour chaque sen/ice on commence par lire I'ldentificateur 
du service et les donnees permettant de localiser le flux de contenu 9.5. 
Pour chaque service, des informations sur ce service peuvent etre 



1 er depot 
21 



contenues dans une plurality de flux de description de service. La 
localisation de cette pluralite de flux de description est precisee dans une 
suite de descripteurs que I'on lit maintenant 9.6 et 9.7. Ensuite on stocke 
pour chaque sen/ice, I'identificateur de flux de transport, I'identificateur de 
5 rdseau d'origine, I'identificateur de service, le descripteur de localisation du 
flux vehiculant le contenu du service (CSL pour « Content Stream Locator ») 
ainsi que le tableau des descripteurs de localisation des flux de description 
du service (SDSL pour « Service Description Stream locator ») 9.8. On 
r§itere ces operations pour chaque service contenu dans le flux de transport 
10 ainsi que pour chaque flux de transport 9.9 et 9.10. De cette mani^re on 
obtient la liste de tous les services disponibles sur le r^seau et les 
descripteurs des flux les diffusant tant pour le contenu que pour les 
informations de description de ces contenus. 

15 La figure 10 detaille un exemple de la fagon dont on peut r6cup6rer 

les informations sur les services une fois que I'on a construit la llste des 
services par le parcours de la NIT modifiee comme explique sur la figure 9. 
Pour recup^rer les informations sur les diff6rents services offerts sur le 
r§seau, le r6cepteur doit trouver les tables de description de service (SDT 
20 pour « Service Description Table ») pour chaque service. Pour ce faire, il 
commence par lire le descripteur du premier service 10.1. Puis il lit le 
premier descripteur de localisation des flux de description du sen/ice (SDSL). 
La. si ce SDSL ne contient pas les champs « Filterjength » et 
« Filter_descriptor » permettant de savoir si le flux d6sign§ contient la SDT. il 
25 doit se connecter au flux 10.9, en lire les sections a la recherche d'une SDT 
dont ndentificateur de table est 0x42. 10.10. 10.11 et 10.12. Dans le cas ou 
les champs « Filterjength » et « Filter_descriptor » existent, il va utiliser ces 
informations pour verifier la presence de la SDT dans le flux 10.3. Si elle 
n'est pas presente, il teste le descripteur suivant 10.13, 10.14 et finit par 
30 supprimer de la liste un sen/ice dont il ne pourrait pas trouver la SDT 10.15. 
Quand il a trouve le flux contenant la SDT, il lit cette table 10.5, y trouve le 
nom du service et du fournisseur de service qu'il stocke en memoire 10.6. 
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Cette operation est faite pour tous les services 10.7, 10.8 et ceci jusqu'a la 
fin de la liste des services 10.16. 

^invention pernriet aux operateurs de reutiliser la majeure partie de 
5 leur chame existante de production, en particulier les multiplexeurs. Le seul 
developpement necessaire est celui de modules de formatage permettant de 
construire des flux ne contenant que les tables de signalisation, toutes ou 
parties et d'eventuellement ne pas les encapsuler dans un flux de transport. 
Ce developpement est minime. Uinvention permet aussi de limiter les 
10 modifications a apporter aux logiciels executes sur les decodeurs. En effet, 
principalement la partie gerant I'interface IP, en lieu et place de Tinterface de 
reception satellite ou cable, est a ajouter, tandis que doit etre legerement 
modifi6e la partie de I'application gerant I'installation. Tout le reste du 
fonctionnement de Tappareil est le m§me que pour un decodeur standard. 
15 De m§me le controle d'acces peut etre repris a I'identique. Uinvention 
permet done I'adoption de la diffusion de services DVB sur un r6seau IP 
large bande en minimisant les investissements et les risques pour les 
operateurs ainsi que I'utilisation de la bande passante disponibie sur le 
reseau. 
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REVENDICATIONS 

1 . Method© de decouverte, par un r^cepteur connects S un reseau 
bidirectionnel. de services numerlques sur le reseau bidirectionnel. 
caract6ris6e en ce qu'elle comporte au moins les 6tapes suivantes : 

- le r6cepteur se connecte a un premier flux ; 

- le r6cepteur extrait dudit flux des informations sur la localisation 
sur le reseau d'une part de flux vehiculant le contenu de ces 
services et d'autre part de flux s^pares, v6hiculant des 
informations de description de ces services ; 

- le recepteur se connecte a au moins une partie des flux v6hiculant 
les informations de description des services de fagon^ obtenir 
des informations sur ces services ; 

- le recepteur utilise ces informations pour construire une liste 
6ventuellement unitaire des services disponibles sur le reseau.- 

2. Methode selon la revendication .1 oCi toutes les tables de 
signalisations relatives ^ un service sont contenues dans au. moins un flux 
different du flux vehiculant le contenu dudit sen/ice. 

3. M§thode selon la revendication 2 contenant une etape de test de 
con-espondance entre un identificateur et un filtre contenu dans le 
descripteur d'un flux permettant de determiner si une table possedant cet 
identificateur est disponible dans ledit flux. 

4. Methode selon I'une des revendications 1 § 3 oCi la premiere 
adresse IP de diffusion et le premier num§ro de port sont entr6s par 
I'utilisateur. 

5. M6thode selon I'une des revendications 1 ^ 3 ou la premiere 
adresse IP et le premier num6ro de port sont obtenus du reseau par le 
recepteur. 
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6. Methode selon Tune des revendications 1 a 5 oCi les flux ne 
contiennent qu'un seul service DVB. 

5 7. Methode selon Tune des revendications 1 a 6 ou la liste des 

services est incluse dans la NIT contenue dans le flux disponibte a la 
premiere adresse IP de diffusion sur le premier port, 

■ 

8. Appareil possedant des moyens de se connecter S une adresse IP 
10 de diffusion via des moyens de connexion a un r§seau IP et des moyens de 

decodage de flux DVB diffuse S cette adresse IP de diffusion, caracterise en 
ce que les moyens de decodage de flux DVB ont la capacite d'analyser une 
NIT, extraite du flux, cdntenant des descripteurs de r6seau adapt^s au 
r^seau IP et de se connecter h ohaque adresse IP de diffusion decrite dans 
15 ladite NIT pour y lire un flux DVB et en extraire les informations sur les 
services offerts sur le r§seau pr6f6rentiellement selon Tune quelconque des 
methodes selon les revendications prec6dentes. 

9. Descripteur d'un service de diffusion d'un flux DVB destine a §tre 
20 inclus dans une NIT caracterise en ce qu'il contient Tadresse IP de diffusion 

d'un serveur de flux et un numero de port sur lequel ledit serveur diffuse un 
flux DVB v6hiculant le contenu d'un service sur un reseau de type IP et au 
moins un descripteur contenant Tadresse IP de diffusion d'un serveur de flux 
et un numero de port sur lequel ledit serveur diffuse un flux DVB v6hiculant 
25 des informations de signalisation relatives audit service. 

10. Descripteur selon la revendication 9 ou les au moins un 
descripteur contenant Tadresse IP de diffusion d'un serveur de flux et un 
num§ro de port sur lequel ledit sen/eur diffuse un flux DVB vehiculant des 

30 informations de signalisation relatives audit service contiennent egalement le 
moyen de tester la correspondance d'un identificateur avec un filtre. 
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/* entete */ 

for i=0 ; i < N ; i++ { /* premiere boucle de descripteurs */ 
descriptorO; 

} 

for i=0 ; i < N ; i++ { /* boucle sur les flux de transport */ 
identificateur_de_ftux_de_transport 
identificateur_de_reseau_original 

for G=0 : j<M ; { /* deuxieme boucle de descripteur */ 

descriptorO; 

} 

} 
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